This description is generated by an AI tool. It may have inaccuracies.
• Adds DroneCAN protocol support to iNav using the libcanard library
• Implements initial GPS driver for DroneCAN devices
• Includes comprehensive DSDL-generated message definitions for DroneCAN and UAVCAN protocols
• Adds DroneCAN driver infrastructure and initialization code
• Includes documentation for DroneCAN support
• Tested with HITL and CAN current sensor
• Resolves issue iNavFlight/inav#11128
• Defers parameter get/set support and CAN error logging to future PRs

Description

This PR adds dsdlc_generated DroneCAN DSDL outputs directly to the repo, which are generated
artifacts and can make builds non-reproducible and the repo noisy. These files should be generated
into the build directory (or updated via an explicit opt-in step) and excluded from normal source
tracking.

Code

src/main/drivers/dronecan/dsdlc_generated/src/uavcan.equipment.air_data.Sideslip.c[R1-8]

+#define CANARD_DSDLC_INTERNAL
+#include "uavcan.equipment.air_data.Sideslip.h"
+#include <string.h>
+
+#ifdef CANARD_DSDLC_TEST_BUILD
+#include <test_helpers.h>
+#endif
+

Evidence

Compliance ID 12 forbids committing generated artifacts; the added file is under dsdlc_generated
and contains CANARD_DSDLC_INTERNAL, indicating it is generated output being tracked in the PR.

src/main/drivers/dronecan/dsdlc_generated/src/uavcan.equipment.air_data.Sideslip.c[1-8]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The PR commits DSDL-generated DroneCAN sources/headers under `dsdlc_generated`, which are generated artifacts.
## Issue Context
Generated artifacts should be produced as part of the build (or via an explicit opt-in update command) and not be committed as normal source to keep the repository clean and reproducible.
## Fix Focus Areas
- src/main/drivers/dronecan/dsdlc_generated/src/uavcan.equipment.air_data.Sideslip.c[1-8]
- cmake/main.cmake[2-12]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new STM32H7 DroneCAN driver uses RxHeader.DataLength directly for memcpy() into an 8-byte
buffer and also assigns it directly to rx_frame->data_len without checking bounds or converting
DLC-to-length semantics. This can cause out-of-bounds reads/writes or incorrect frame lengths when
the header encoding differs from a raw byte count.

Code

src/main/drivers/dronecan/libcanard/canard_stm32h7xx_driver.c[R64-117]

+		rx_frame->data_len = RxHeader.DataLength;
+		memcpy(rx_frame->data, RxData, RxHeader.DataLength);
+
+		// assume a single interface
+		rx_frame->iface_id = 0;
+
+		return 1;
+	}
+
+	// Either no CAN msg to be read, or an error that can be read from hfdcan->ErrorCode
+	return 0;
+}
+
+/**
+  * @brief  Process tx_frame CAN message into Tx FIFO/Queue and transmit it
+  * @param  tx_frame pointer to a CanardCANFrame structure that contains the CAN message to
+  * 		transmit.
+  * @retval ret == 1: OK, ret < 0: CANARD_ERROR, ret == 0: Check hfdcan->ErrorCode
+  */
+int16_t canardSTM32Transmit(const CanardCANFrame* const tx_frame) {
+	if (tx_frame == NULL) {
+		return -CANARD_ERROR_INVALID_ARGUMENT;
+	}
+
+	if (tx_frame->id & CANARD_CAN_FRAME_ERR) {
+		return -CANARD_ERROR_INVALID_ARGUMENT; // unsupported frame format
+	}
+
+	FDCAN_TxHeaderTypeDef TxHeader;
+	uint8_t TxData[8];
+
+	// Process canard id to STM FDCAN header format
+	if (tx_frame->id & CANARD_CAN_FRAME_EFF) {
+		TxHeader.IdType = FDCAN_EXTENDED_ID;
+		TxHeader.Identifier = tx_frame->id & CANARD_CAN_EXT_ID_MASK;
+	} else {
+		TxHeader.IdType = FDCAN_STANDARD_ID;
+		TxHeader.Identifier = tx_frame->id & CANARD_CAN_STD_ID_MASK;
+	}
+
+	TxHeader.DataLength = tx_frame->data_len;
+
+	if (tx_frame->id & CANARD_CAN_FRAME_RTR) {
+		TxHeader.TxFrameType = FDCAN_REMOTE_FRAME;
+	} else {
+		TxHeader.TxFrameType = FDCAN_DATA_FRAME;
+	}
+
+	TxHeader.ErrorStateIndicator = FDCAN_ESI_ACTIVE; // unsure about this one
+	TxHeader.BitRateSwitch = FDCAN_BRS_OFF; // Disabling FDCAN (using CAN 2.0)
+	TxHeader.FDFormat = FDCAN_CLASSIC_CAN; // Disabling FDCAN (using CAN 2.0)
+	TxHeader.TxEventFifoControl = FDCAN_NO_TX_EVENTS; // unsure about this one
+	TxHeader.MessageMarker = 0; // unsure about this one
+	memcpy(TxData, tx_frame->data, TxHeader.DataLength);

Evidence

Compliance ID 9 requires validating external payload lengths before reading/copying; the code copies
RxHeader.DataLength bytes into a fixed 8-byte buffer and similarly uses tx_frame->data_len as
the HAL DataLength without validation/conversion.

src/main/drivers/dronecan/libcanard/canard_stm32h7xx_driver.c[64-65]
src/main/drivers/dronecan/libcanard/canard_stm32h7xx_driver.c[104-117]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`RxHeader.DataLength`/`TxHeader.DataLength` are used as raw byte counts for `memcpy()` without conversion or bounds checks, risking buffer overruns or invalid CAN frames.
## Issue Context
These values may be DLC-encoded or otherwise not guaranteed to be <= 8; even if classic CAN is intended, defensive checks are required for external inputs.
## Fix Focus Areas
- src/main/drivers/dronecan/libcanard/canard_stm32h7xx_driver.c[64-65]
- src/main/drivers/dronecan/libcanard/canard_stm32h7xx_driver.c[104-117]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

canardSTM32ComputeTimings() returns bool but its result is ignored and out_timings is used
unconditionally to configure the peripheral. If timing computation fails, CAN may be initialized
with invalid/uninitialized timing values without any error propagation.

Code

src/main/drivers/dronecan/libcanard/canard_stm32h7xx_driver.c[R162-168]

+  canardSTM32ComputeTimings(bitrate, &out_timings);
+
+  hfdcan1.Init.NominalPrescaler = out_timings.prescaler;
+  hfdcan1.Init.NominalSyncJumpWidth = out_timings.sjw;
+  hfdcan1.Init.NominalTimeSeg1 = out_timings.bs1;
+  hfdcan1.Init.NominalTimeSeg2 = out_timings.bs2;
+  LOG_DEBUG(CAN, "Prescaler: %d, SJW: %d, BS1: %d, BS2: %d", out_timings.prescaler, out_timings.sjw, out_timings.bs1, out_timings.bs2);

Evidence

Compliance ID 3 requires handling failure points; the timing computation has a failure return but
the caller does not check it and proceeds using out_timings.

Rule 3: Generic: Robust Error Handling and Edge Case Management
src/main/drivers/dronecan/libcanard/canard_stm32h7xx_driver.c[162-168]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
CAN timing computation failure is ignored, potentially configuring hardware with invalid values.
## Issue Context
The timing helper explicitly returns `false` for invalid/unsatisfied configurations; initialization should not proceed on failure.
## Fix Focus Areas
- src/main/drivers/dronecan/libcanard/canard_stm32h7xx_driver.c[162-168]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Multiple DroneCAN handlers drop messages by returning immediately when *_decode() fails without
logging or any other error signal. This creates silent failures that are hard to diagnose in-field.

Code

src/main/drivers/dronecan/dronecan.c[R51-115]

+	if (uavcan_protocol_NodeStatus_decode(transfer, &nodeStatus)) {
+		return;
+	}
+
+	// LOG_DEBUG(CAN, "Node Health ");
+
+	switch (nodeStatus.health) {
+	case UAVCAN_PROTOCOL_NODESTATUS_HEALTH_OK:
+		// LOG_DEBUG(CAN, "OK");
+		break;
+	case UAVCAN_PROTOCOL_NODESTATUS_HEALTH_WARNING:
+		// LOG_DEBUG(CAN, "WARNING");
+		break;
+	case UAVCAN_PROTOCOL_NODESTATUS_HEALTH_ERROR:
+		// LOG_DEBUG(CAN, "ERROR");
+		break;
+	case UAVCAN_PROTOCOL_NODESTATUS_HEALTH_CRITICAL:
+		// LOG_DEBUG(CAN, "CRITICAL");
+		break;
+	default:
+		// LOG_DEBUG(CAN, "UNKNOWN?");
+		break;
+	}
+
+	// LOG_DEBUG(CAN, "Node Mode ");
+
+	switch(nodeStatus.mode) {
+	case UAVCAN_PROTOCOL_NODESTATUS_MODE_OPERATIONAL:
+		// LOG_DEBUG(CAN, "OPERATIONAL");
+		break;
+	case UAVCAN_PROTOCOL_NODESTATUS_MODE_INITIALIZATION:
+		// LOG_DEBUG(CAN, "INITIALIZATION");
+		break;
+	case UAVCAN_PROTOCOL_NODESTATUS_MODE_MAINTENANCE:
+		// LOG_DEBUG(CAN, "MAINTENANCE");
+		break;
+	case UAVCAN_PROTOCOL_NODESTATUS_MODE_SOFTWARE_UPDATE:
+		// LOG_DEBUG(CAN, "SOFTWARE UPDATE");
+		break;
+	case UAVCAN_PROTOCOL_NODESTATUS_MODE_OFFLINE:
+		// LOG_DEBUG(CAN, "OFFLINE");
+		break;
+	default:
+		// LOG_DEBUG(CAN, "UNKNOWN?");
+		break;
+	}
+}
+
+void handle_GNSSAuxiliary(CanardInstance *ins, CanardRxTransfer *transfer) {
+	UNUSED(ins);
+    struct uavcan_equipment_gnss_Auxiliary gnssAuxiliary;
+
+	if (uavcan_equipment_gnss_Auxiliary_decode(transfer, &gnssAuxiliary)) {
+		return;
+	}
+    LOG_DEBUG(CAN, "GNSS Auxiliary: Num Sats: %d, HDOP %.2f", gnssAuxiliary.sats_used, (double)gnssAuxiliary.hdop);
+}
+
+void handle_GNSSFix(CanardInstance *ins, CanardRxTransfer *transfer) {
+	UNUSED(ins);
+    struct uavcan_equipment_gnss_Fix gnssFix;
+
+	if (uavcan_equipment_gnss_Fix_decode(transfer, &gnssFix)) {
+		return;
+	}

Evidence

Compliance ID 3 forbids silent failures/ignored errors; the new handlers discard failed decodes with
return; and provide no context about which message failed or why.

Rule 3: Generic: Robust Error Handling and Edge Case Management
src/main/drivers/dronecan/dronecan.c[51-53]
src/main/drivers/dronecan/dronecan.c[113-115]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Decode failures are silently ignored, making it difficult to detect malformed frames or schema mismatches.
## Issue Context
This is a new external-input path (CAN bus) where malformed payloads are expected; diagnostics should be available without flooding logs.
## Fix Focus Areas
- src/main/drivers/dronecan/dronecan.c[47-129]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The new debug logging prints raw GPS latitude/longitude values, which can be sensitive location
data, and uses unstructured log strings. This may violate secure logging requirements and makes
automated log analysis harder.

Code

src/main/drivers/dronecan/dronecan.c[R106-135]

+    LOG_DEBUG(CAN, "GNSS Auxiliary: Num Sats: %d, HDOP %.2f", gnssAuxiliary.sats_used, (double)gnssAuxiliary.hdop);
+}
+
+void handle_GNSSFix(CanardInstance *ins, CanardRxTransfer *transfer) {
+	UNUSED(ins);
+    struct uavcan_equipment_gnss_Fix gnssFix;
+
+	if (uavcan_equipment_gnss_Fix_decode(transfer, &gnssFix)) {
+		return;
+	}
+    dronecanGPSReceiveGNSSFix(&gnssFix);
+    LOG_DEBUG(CAN, "GNSS Fix: Longitude: %lld, Latitude %lld", gnssFix.longitude_deg_1e8, gnssFix.latitude_deg_1e8);
+}
+
+void handle_GNSSFix2(CanardInstance *ins, CanardRxTransfer *transfer) {
+	UNUSED(ins);
+    struct uavcan_equipment_gnss_Fix2 gnssFix2;
+
+	if (uavcan_equipment_gnss_Fix2_decode(transfer, &gnssFix2)) {
+		return;
+	}
+    dronecanGPSReceiveGNSSFix2(&gnssFix2);
+    LOG_DEBUG(CAN, "GNSS Fix2: Longitude: %lld, Latitude %lld", gnssFix2.longitude_deg_1e8, gnssFix2.latitude_deg_1e8);
+}
+
+void handle_GNSSRCTMStream(CanardInstance *ins, CanardRxTransfer *transfer) {
+	UNUSED(ins);
+    struct uavcan_equipment_gnss_RTCMStream gnssRTCMStream;
+
+	if (uavcan_equipment_gnss_RTCMStream_decode(transfer, &gnssRTCMStream)) {

Evidence

Compliance ID 5 requires avoiding sensitive data in logs and using structured logging; the added
LOG_DEBUG() lines emit raw GNSS coordinates in free-form strings.

Rule 5: Generic: Secure Logging Practices
src/main/drivers/dronecan/dronecan.c[106-107]
src/main/drivers/dronecan/dronecan.c[117-118]
src/main/drivers/dronecan/dronecan.c[128-129]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Logs include raw GNSS coordinates and unstructured strings.
## Issue Context
Location data can be sensitive; logs should avoid detailed location output by default and be machine-parseable where possible.
## Fix Focus Areas
- src/main/drivers/dronecan/dronecan.c[99-135]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

handle_GetNodeInfo() and send_NodeStatus() allocate `uint8_t
buffer[UAVCAN_PROTOCOL_GETNODEINFO_RESPONSE_MAX_SIZE]` on the stack, where the max is 377 bytes. In
embedded/IO paths this increases stack pressure and risk of overflow, especially if called in
constrained task contexts.

Code

src/main/drivers/dronecan/dronecan.c[R158-205]

+	printf("GetNodeInfo request from %d", transfer->source_node_id);
+
+	uint8_t buffer[UAVCAN_PROTOCOL_GETNODEINFO_RESPONSE_MAX_SIZE];
+	struct uavcan_protocol_GetNodeInfoResponse pkt;
+
+	memset(&pkt, 0, sizeof(pkt));
+
+	node_status.uptime_sec = HAL_GetTick() / 1000ULL;
+	pkt.status = node_status;
+
+	// fill in your major and minor firmware version
+	pkt.software_version.major = FC_VERSION_MAJOR;
+	pkt.software_version.minor = FC_VERSION_MINOR;
+	pkt.software_version.optional_field_flags = FC_VERSION_PATCH_LEVEL;
+	pkt.software_version.vcs_commit = 0; // shortGitRevision; // need to convert string to integer put git hash in here
+
+	// should fill in hardware version
+	pkt.hardware_version.major = 1;
+	pkt.hardware_version.minor = 0;
+
+	// just setting all 16 bytes to 1 for testing
+	canardSTM32GetUniqueID(pkt.hardware_version.unique_id);
+
+	strncpy((char*)pkt.name.data, FC_FIRMWARE_NAME, sizeof(pkt.name.data));
+	pkt.name.len = strnlen((char*)pkt.name.data, sizeof(pkt.name.data));
+
+	uint16_t total_size = uavcan_protocol_GetNodeInfoResponse_encode(&pkt, buffer);
+
+	canardRequestOrRespond(ins,
+						   transfer->source_node_id,
+						   UAVCAN_PROTOCOL_GETNODEINFO_SIGNATURE,
+						   UAVCAN_PROTOCOL_GETNODEINFO_ID,
+						   &transfer->transfer_id,
+						   transfer->priority,
+						   CanardResponse,
+						   &buffer[0],
+						   total_size);
+}
+
+// Canard Senders
+
+/*
+  send the 1Hz NodeStatus message. This is what allows a node to show
+  up in the DroneCAN GUI tool and in the flight controller logs
+ */
+void send_NodeStatus(void) {
+    uint8_t buffer[UAVCAN_PROTOCOL_GETNODEINFO_RESPONSE_MAX_SIZE];
+

Evidence

Compliance ID 13 recommends avoiding large stack buffers in sensitive embedded/IO paths; the PR
introduces 377-byte stack allocations in message handlers/senders.

src/main/drivers/dronecan/dsdlc_generated/include/uavcan.protocol.GetNodeInfo_res.h[10-16]
src/main/drivers/dronecan/dronecan.c[158-161]
src/main/drivers/dronecan/dronecan.c[203-205]
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Large stack buffers are allocated in DroneCAN handler/sender paths, increasing stack pressure.
## Issue Context
Embedded systems often have small stacks per task/ISR; using static/shared buffers or preallocated pools is safer.
## Fix Focus Areas
- src/main/drivers/dronecan/dronecan.c[158-205]
- src/main/drivers/dronecan/dsdlc_generated/include/uavcan.protocol.GetNodeInfo_res.h[10-16]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools